Этой весной в хабраблоге ВКонтакте написали «Мы готовы начать говорить о том, что находится за фасадом продукта». Мы не стали упускать возможность — и в преддверии JavaScript-конференции HolyJS, где разработчик VK Тимофей Чаптыков выступит с докладом, задали ему несколько вопросов.
— Чем именно вы занимаетесь в ВК?
— Преимущественно я занимаюсь разработкой раздела сообщений. Но у нас маленькая команда, и зона ответственности каждого разработчика достаточно широкая. И чем дольше человек здесь работает, тем она шире.
— До работы в ВК вы жили в Новосибирске — из-за этой работы и переехали? Недавно новосибирский Java-разработчик рассказывал нам, что ему и в Новосибирске отлично живётся, а что в городе с JavaScript и фронтендом — много ли вакансий, развито ли местное JS-сообщество?
— За прошлый год я побывал в Питере четыре раза. В какой-то момент решил, что проще переехать. Ну и отказаться от предложения поработать над одним из самых больших, сложных и массовых проектов с крайне взыскательной аудиторией было сложно.
В Новосибирске достаточно много крупных IT-компаний, у которых есть вакансии в веб-разработке: Яндекс, 2ГИС, JetBrains, СберТех, Tinkoff.ru. Так что я бы сказал, что в Новосибирске есть ребята, которые умеют делать сложный масштабируемый фронтэнд. Есть несколько локальных конференций и митапов, раз в год проводится одна из крупнейших в России IT-конференций CodeFest.
— У ВК почти 100-миллионная месячная аудитория. Как такая посещаемость влияет на разработку вообще и JS/фронтенд в частности?
— Сейчас все изменения сначала выпускаются для небольшого процента пользователей. По этим пользователям мы собираем отдельную статистику. Она помогает нам оценить, повлияет ли релиз на нагрузку.
Иногда этого недостаточно. Некоторые фичи мы выкатываем только по ночам, если допускаем возможность, что релиз может повлиять на производительность и работу под нагрузкой. Ночью по московскому времени нагрузка ниже, и если мы увидим аномалии на графиках, то успеем откатить изменения или выпустить хотфиксы до того, как наступит пиковая нагрузка и появится риск сбоя сервиса.
При нашей нагрузке мы не можем позволить себе простые подходы к обновлению статики. Мы не можем себе позволить объединить все скрипты в один файл и обновлять его при каждом деплое. Если все пользователи придут одновременно за файлом, выдержать нагрузку будет сложно. Один лишний запрос, который сделают 100 миллионов пользователей, может привести к катастрофическим последствиям. Поэтому мы версионируем статику, подгружаем динамически (страница будет подгружать ту версию статики, которая с ней совместима), разбиваем на небольшие куски по разделам и возможностям сайта.
Некоторые изменения мы вообще не можем вносить напрямую. Мы же не можем выключить сайт на несколько дней, пока проводится миграция базы с миллиардами записей. =)
Когда у тебя 100 миллионов активных пользователей в месяц, теория вероятности начинает работать против тебя. Количество экспериментов такое, что невозможные события становятся ежедневной рутиной. Если баг воспроизводится один раз на миллион, это значит, что этот баг будет воспроизводиться много раз ежедневно. Надо прорабатывать детально даже совсем невероятные сценарии.
На фронтенде сказывается то, что иногда кейсы использования ВКонтакте сильно отличаются от других сайтов. Например, время жизни вкладки с сообщениями может быть почти бесконечным: вы открываете вкладку, и она живёт месяцами. Это заставляет нас больше думать о расходе памяти.
Иногда жёсткие требования по производительности возникают от большого объёма кода. Например, сборку пришлось организовать не совсем тривиально и мейнстримно.
Я думаю, нам чаще, чем большинству разработчиков, приходится думать о структурах данных, в том числе на клиенте. На нашей кухне чаще услышишь разговоры об алгоритмах и структурах данных, чем о новых библиотеках и методологиях.
На сайте мы почти не используем внешние зависимости. Технически каждый раздел на клиенте — это отдельное JS-приложение. Из общих ресурсов — система для кодсплиттинга и версионирования статики, работа с мультиязычностью, утилиты для работы с DOM, запросами на сервер, небольшое общее хранилище, некоторые переиспользуемые решения для пользовательского интерфейса.
— Ещё давно, когда Node.js был малоизвестным нишевым решением, его популяризатором в России стал разработчик ВК Олег Илларионов. А используют ли Node.js в ВК сейчас, когда это уже более чем мейнстрим?
— В большинстве случаев мы по объективным причинам не можем использовать Node.js на бэкенде — слишком медленно на наших объёмах. Поэтому мы, как и вся индустрия, используем Node.js для сборки фронтенда. А там мы используем традиционный набор инструментов: Gulp, Webpack, Babel.
— Ранее ВКонтакте выкладывали в опенсорс собственные KPHP-наработки — а в случае с JS у соцсети есть какие-то значительные внутренние «велосипеды», которые теоретически могут когда-то оказаться в опенсорсе, или там в основном пользуетесь готовыми решениями?
— У нас в продакшене используется очень мало готовых решений. В package.json в основном репозитории объявлены только 4 зависимости. Две из них — полифиллы, две — библиотеки для записи и кодирования звука в mp3.
Значительных внутренних велосипедов много. Но часто наши решения узкоспециализированные, они не будут востребованы в «массовом» секторе разработки. Например, инфраструктура вокруг KPHP имеет достаточно высокий порог входа, его использование накладывает определённые ограничения. А проектов, на которых можно было бы ощутить значительную пользу от его внедрения, не так много.
Тем не менее, я рассчитываю, что открытого программного обеспечения в области фронтенда у нас будет больше.
— JS-мир часто критикуют с позиций «в современном фронтенде, чтобы написать “Hello world”, нужно 360 МБ зависимостей». А при работе в ВК это приносит неудобства, или в таком масштабном проекте это незначимый фактор по сравнению с другими?
— Ну, это точно не главная проблема, которую нам предстоит решить =) У нас 140 МБ зависимостей в node_modules. На мой взгляд, один из самых серьёзных технических вызовов — устранение технического долга и развитие инфраструктуры для разработки и тестирования. В наших реалиях мы должны это делать без снижения темпов разработки новых фич. И всё той же командой в несколько десятков разработчиков на все наши продукты.
— Ваш доклад на HolyJS называется «React со скоростью света: не совсем обычный серверный рендеринг». А не мешает ли вам использовать React то, что он создан в Facebook? 🙂
— Приходите на доклад, там я расскажу, что итоговое решение не основано на React =)
Я бы рассматривал React скорее как термин, обозначающий подход, чем как название конкретной библиотеки. Говоря про React, мы обычно имеем в виду Virtual DOM, декларативный рендеринг, компонентный подход, JSX.
В большинстве случаев React можно с минимальными усилиями заменить на другую библиотеку, которая использует те же принципы. А ещё найти какие-нибудь бенчмарки, которые покажут, что выбранное решение при определённых обстоятельствах работает быстрее. =)
Мне нравится Preact — крошечная библиотека в 4 КБ, которая предоставляет все базовые возможности, к которым мы привыкли в React.
Непосредственно React сейчас не используется на сайте ВКонтакте, но есть в нескольких наших проектах. Например, VK Messenger — это десктопное приложение на Electron, написанное на React.
— Спасибо. Напоследок хочется уточнить из-за вашего ироничного твита про счётчик уведомлений: а можете для всех, кто с этим не сталкивается профессионально, кратко объяснить, почему это сложная задача?
— Счётчик новых уведомлений — одно число, которое выводится в результате работы огромного количества систем. Причём обычно это сложные и запутанные многоуровневые системы с кэшированием, асинхронным выполнением задач, очередями и вычислениями, которые проводятся на огромном количестве серверов. В результате сбой любой части любой из этих систем может привести к тому, что пользователь увидит неправильное значение на счётчике.
Мне кажется, иронично, что сложность систем в IT постоянно привлекает к себе моё внимание поломанными красными счётчиками у некоторых приложений на моём телефоне.
ссылка на оригинал статьи https://habrahabr.ru/post/330000/
Добавить комментарий